POV-Ray : Newsgroups : povray.general : Issue with function parameters : Re: Issue with function parameters Server Time
3 Aug 2024 12:19:36 EDT (-0400)
  Re: Issue with function parameters  
From: Marvin Taylor
Date: 13 Feb 2004 18:17:46
Message: <402d5b1a$1@news.povray.org>
Thorsten Froehlich wrote:
> In article <402d339c@news.povray.org> , Florian Brucker <tor### [at] torfboldcom>
> wrote:
> 
> 
>>in math.inc. With the current behaviour, I cannot use V, A, B, N, Mn,
>>Mx, OMn and OMx as identifier names before including math.inc, because
>>they are function parameters of functions declared in math.inc :(
>>If the current behaviour is really necessary (and I doubt it is),
> 
> It is absolutely necessary.  What you expect is functions to have a scope on
> the same level as macros do.  This is not the case, and you don't want it to
> be the case either (it is possible to construct cases where, if this would
> be the case, it would badly break functions - i.e. when generating a
> function with macros).

Unless I misunderstand the question, he was asking why a named parameter 
(to a macro or a function) would be masked by a symbol from the global 
namespace.  It seems that your answer is that *macros* and *functions* 
should be scoped differently (which makes sense) but doesn't seem to 
apply to the scoping of the *parameters*.

Sorry to be dense, but I've re-read this about 5 times and it seems like 
you either didn't answer the question or I'm missing something.

So, can you please give an example?  When would it be important that the 
*named parameter* of a macro be altered by a global #declare?

Offhand it seems like a flaw in the parser handling of *parameters* of 
macros, albeit one that could be worked-around by applying a naming 
convention to the standard include files.

[BTW, I've written parsers/compilers/interpreters but haven't poked 
around in POV's source code.]

> The solution is that the include files should not use generic names for
> function variable names.  A good solution would be to use all lower case
> variable names with a prefix, i.e. "math__a" (note the *two* underscore
> chars, this makes sure this will never be a keyword) instead of "A" in
> math.inc .  This would work because the documentation already suggests to
> the user to never use all lower case names.

Incidentally, the documentation says for identifiers "the first 
character must be an alphabetic character" -- but underscores are 
apparently allowed (v3.5).

That said, I'd for my $.02 a double-underscore prefix would be shorter 
and easier to read:

    #declare atan2d = function (__a, __b) {degrees(atan2(__a, __b))}

However that would presume that the POV documentation state that POV 
won't use an underscore to start keywords, and the users should not use 
them except for parameters.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.